1. Technical Field
The present teaching generally relates to a computer. More specifically, the present teaching relates to computerized intelligent human-machine interaction.
2. Technical Background
With advancement of artificial intelligence technologies and the explosion of e-commerce due to the ubiquitous Internet's connectivity, computer aided dialogue systems have become increasingly popular. For example, more and more call centers deploy automated dialogue robot to handle customer calls. Hotels started to install various kiosks that can answer questions from tourists or guests. Online bookings (whether travel accommodations or theater tickets, etc.) are also more frequently done by chatbots. More and more applications such as games have sessions in which machine (the game server or agent) may have dialogues with a player.
A traditional human-machine dialogue framework is shown in FIG. 1 (PRIOR ART). In this framework, a user having a user device, e.g., 110-a, may interact with an application client, e.g., 140-a (e.g., a game engine), to carry out some programmed tasks (e.g., games). The application client 140-a may be supported by a backend system or application server 130, which carries out, e.g., significant computation work in order to support the operations of different application clients. For example, different applications may instruct different user devices to render different objects in order to render the underlying applications, respectively. In the case of game applications, each user device may be running with a different game and at different stages of the games may require rendering different objects.
In operation, in order to continue the application, the user device 110-a may provide information about its application states to a corresponding application client 140-a via the network 120. Upon receiving the application states, the application client 140-a may forward the application state information to the application server 130 and communicate with the application server 130 as to how to proceed with the game. The application server 130 may determine how to proceed with the game and accordingly instruct the application client 140-a to render an object on the user device 110-a. In such a situation, the application server 130 will send a model of the object to the application client 140-a and then the application client 140-a will forward the model to the user device 110-a so that the object can be rendered on the user device based on the model of the object. In the traditional system, the model to be used to render the object from the application server 130 fully describes the details related to the rendering, e.g., the object to be rendered (e.g., avatar), the appearance of the object, e.g., the avatar is a female, has green skin, red eyes, wrinkle skin, blue shirt, naked legs, long hair, etc.
In the framework shown in FIG. 1, the application server 130 is the backend support for many application clients 140. When models sent to the user device contain all the details related to rendering, each model takes much space and requires high bandwidth to be transmitted to the application clients. This makes the application server more difficult to scale its operation. In addition, when the application server 130 dictates how the objects are to be rendered, no consideration is taken as to who is playing the game or in what setting the user is playing the game. That is, there is no individual flavor to each game player or to each application client. This makes it less interesting to the players and may make it more difficult to engage the user.
Thus, there is a need for methods and systems that address such limitations.